1. Technical Field
The present invention relates to the field of logic simulation and, more particularly, to simulating and processing signals within logic simulators.
2. Description of the Related Art
A logic simulator is a software tool which is capable of performing functional and timing simulations for digital electronic designs which are written in a hardware description language such as Very High Speed Hardware Description Language (VHDL) or Verilog. VHDL, for example, permits hardware designers to define signals at a very high level of abstraction. The abstracted signal representations can be translated to actual pins on a microchip using any of a variety of commercial electronic design automation (EDA) software tools.
VHDL provides a measure of flexibility by allowing hardware designers to declare signals of various user defined types. A user-defined type can either be a scalar or a composite type. Scalars further can be subdivided into four different types, namely enumeration, integer, floating point, and physical. Composites, however, can be subdivided into two types: arrays and records.
A scalar type defines a single value for a signal and a composite type defines a collection of values. New values can be assigned to signals through signal assignment statements. A signal assignment statement defines a container for a new projected output waveform for the signal. Such a container is referred to as the driver of the target signal. A pair which includes a new value and the time at which the signal is to assume this new value is called a transaction. For a scalar target signal there can be only one driver and one waveform. For a composite target signal, however, the composite signal is thought of as an aggregation of multiple scalar signals. A composite signal can include N drivers and N waveforms, where one waveform is attached to each driver and where N is total number of scalar signals contained in the given composite signal. The projected waveform of a scalar driver has transactions that occur as the time component increases.
Transactions can be scheduled using one of two different techniques. The first technique, called transport scheduling, truncates any previous transaction whose time component is greater than the time component of the new transaction being scheduled. The second technique, referred to as inertial scheduling, takes a rejection limit and goes further than the truncation technique. More particularly, after truncating transactions whose time component is greater than the new transaction being scheduled, inertial rejection rejects all transactions in the rejection limit window except for transactions which immediately precede the new transaction and whose value component is the same as the new transaction being scheduled. The transaction that determines the current value of the driver is excluded from rejection as well.
FIG. 1 is a schematic diagram illustrating a conventional manner of illustrating waveform transactions. As shown, composite signal S contains 4 scalar signals. Each scalar signal has a driver and a corresponding waveform which takes on particular values at given times. The event queue includes four time slots corresponding to times of 5 nanoseconds (ns), 6 ns, 7 ns, and 9 ns. A time slot in the event queue includes all transactions that have a time value which is the same as the time value of the time slot. The transactions, for example, can be maintained in a list.
In illustration, FIG. 1 illustrates the current state of the composite waveform S and the event queue at the current time, or “now” time, of 5 ns. The following signal assignment statement can be executed: “S<=reject 3 ns inertial “10UX” after 5 ns”. This signal assignment statement will create four new transactions which will be appended to the scalar waveforms and the event queue.
FIG. 2 is a schematic diagram that illustrates the state of signal S after execution of the signal assignment statement. The transactions in each waveform are in increasing order with respect to time.
In performing inertial rejection, any previously scheduled transaction which is scheduled to occur at or after the time of the new transaction is deleted. No such transactions exist within FIG. 2. All transactions in the rejection window, which can be calculated as (the time of the new transaction)−(time of the rejection), can be examined for possible rejection. In this case, the equation becomes 10 ns−3 ns=7 ns.
Continuing with FIG. 3, the transactions within the rejection window, i.e., those transactions occurring at 7 and 9 ns can be analyzed. In particular, transactions occurring in the rejection window, with the exception of transactions occurring at the current time, should that timeslot fall within the rejection window, or transactions which have a value which is the same as the newly added transaction can be deleted or marked unscheduled. Accordingly, the transactions which have been marked unscheduled, i.e., the transaction having a value of 1 for driver 1 at 7 ns and the transaction having a value of X for driver 2 at 9 ns, have been indicated with bolded perimeters.
Since each scalar signal contained in a composite signal must keep that scalar signal's own waveform, a transaction to a composite signal with N scalar signals needs to add N transactions in order to project the waveform of the scalar drivers. In addition, N transactions must be scheduled and processed on the event queue. If the scalar drivers are aggregated, the scheduling and processing of transactions have a complexity on the order of N because individual projected waveforms of scalar signals must be preserved for the inertial rejection technique to function properly.
In consequence, the amount of time required to perform inertial rejection using software simulation tools can be significant as the sheer number of calculations necessary can be quite extensive. What is needed is an improved technique for modeling transactions that reduces the time required for scheduling and transaction processing; as well as an improved technique for performing inertial rejection that utilizes fewer processing resources, less simulation time, and therefore reduces the time required for design and implementation.